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Кто использует SQL? 


e “Классические” СУБД (MySQL, Postgres, SQL Server, Oracle) 
e “Новые” системы управления данными 


о Реляционные (CockroachDB, TiDB, YugaByte) 
o  BigData/Analytics (Hive, Snowflake, Dremio, Clickhouse, Presto) 
o NoSQL (DataStax*, Couchbase*) 
o . Compute/streaming (Spark, ksqIDB, Apache Flink) 
o  |n-memory (Apache Ignite, Gigaspaces) 
e Бунтари 
o Мопдорв 
o Веаіѕ 


* Используют $01-подобный синтаксис 


e “Классические” СУБД (MySQL, Postgres, SQL Server, Oracle) 


e “Новые” системы управления данными 


JavaScript 


HTML/CSS 


SQL 


Python 


o Реляционные (CockroachDB, TiDB, YugaByte) 
o  BigData/Analytics (Hive, Snowflake, Dremio, Clickhouse, Presto) 
o NoSQL (DataStax*, Couchbase*) 
o . Compute/streaming (Spark, ksqIDB, Apache Flink) 
o  In-memory (Apache Ignite, Gigaspaces) 
e Бунтари 
o Мопдорв 
о  Redis 


* Используют $01-подобный синтаксис 


https://insights.stackoverflow.com/survey/2020 


Java 


Bash/Shell/PowerShell 
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TypeScript 


Что такое Hazelcast МОС? 


goog 


Partition Node Cluster 


e  Hazelcast IMDG — это распределенное key-value-xpauunuuije 
e Пары ключ-значение организованы B шарды (partition), которые распределены no узлам кластера 


Зачем нам нужен SQL? 


WHERE key = 10 WHERE age » 30 


e — Доступ только по ключу 
e Хотим делать более сложный анализ: поиск по предикату, агрегации, joins, ... 
e Хотим интеграцию с другими продуктами через драйвера (Hanp., JDBC) 


Что у нас было? 


e Predicate АРІ — возможность найти данные по предикату 
e = |П-тетогу-индексы для ускорения поиска по предикату 


o Heap: конкурентный skip-list 
o О#һеар: самописное однопоточное красно-чёрное дерево 


lMapsLong, Person» map =... 


пар.риї (11, new Person("John")); 


Predicate predicate = Predicates.equals("name", “Јоһп”); 
Collection<Person> persons = map.values (predicate); 


Что не так c Predicate API? 


Работает с множествами, а не курсорами, может упасть с ООМЕ 
Ограниченный функционал (например, не умеет делать join) 

Не является декларативным: необходимо компилировать и деплоить 
Необходимо разбираться с документацией 


lMapsLong, Person» map =... 


пар.риї (11, new Person("John")); 


Predicate predicate = Predicates.equals("name", “Јоһп”); 
Collection<Person> persons = map.values (predicate); 


Что мы сделали? 


e 501 -оптимизатор на основе Apache Calcite 
e Протокол распределенного выполнения запросов 
e Неблокирующая кооперативная модель параллельной обработки запросов 


IMap«Long, Person» map = instance.getMap ("person"); 


try (SqlResult result = instance.getSql().query("SELECT id, name FROM person") { 


for (SqlRow row : result) { 
System.out.println("Name: " + row.getObject ("name")); 


Устройство SQL-onTumusatopa 


Syntax ans Semantic Intermediate 
Analysis Representation 


Attributes __ 
GROUP BY 


SELECT dept.name, COUNT(*) 
FROM emp, dept 
WHERE 

emp.dept id - dept.id 
GROUP BY dept.name 


Backend 


Как сделать 5ОЁ-оптимизатор? 


ө Задача: принять строку, отдать план выполнения 
e Можно писать самому: 
o Парсер 
o Семантический анализатор 
о Трансформации 
e Можно собрать из готовых компонентов: 
о Генераторы парсеров или готовые парсеры 
o X Apache Calcite — фреймворк для построения ЗО! -движков 
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Оптимизация c Apache Calcite 


Optimization 


Ta 


Semantic Analyzer {= 


> Relational Translator 
Optimizer | ] = 


Cost Model 


Metadata | 


Transformations 


Проекты, которые используют Apache Calcite 


e Data Management: 
o X Apache Hive 


o X Apache Flink 
o  Dremio 
o . VoltDB 
[9] 
[9] wes 
e Applied: 


o Alibaba / Ant Group 


o Uber 
о LinkedIn 
[9] 


https://calcite.apache.org/docs/powered_by.htm 


IMDGs (Apache Ignite, Hazelcast, Gigaspaces) 


Used by 
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Connects to 


Є e 
= Spock 
JDBC 

splunk> [№ 


AEF {JSON} 


& elasticsearch 
) mongo DB 


A” APACHE 


2.7 GEODE 


Парсинг 


e Задача: превратить строку в синтаксическое дерево 
e Парсингс Apache Calcite 


О 


О 


Использует JavaCC для генерации парсера 

Имеет готовый к использованию сгенерированный парсер, 
SQL03 

Допускает расширения синтаксиса 


Attributes | 


GROUP BY 


SELECT. 


emp.dept id 


dept.id 
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Семантический анализ 


e Задача: убедиться в семантической | СОЯ 
корректности синтаксического дерева: АШБЩеЗ 777] deptname | ^. 
o Разрешение объектов СУБД (таблицы, | с 
колонки, ...) 
о Разрешение функций 
о Вывод типов 


о Проверка реляционной семантики "7 
e Семантический анализ B Apache Calcite Operator 
COUNT | 


o Предоставьте схему 
о (опционально) Предоставьте кастомные 


функции 
о Запустите встроенный валидатор p 3 
р ] *.| Column 
Column [| Operator AH 
emp.dept id | = 


oe 


emp.dept_id 


dept.id 


Схема B Hazelcast 


e  Hazelcast He имеет схемы, значит нам 
надо ее “придумать” 
Представляем каждый IMap как таблицу 
Находим первую key-value-napy в IMap, 
извлекаем из нее атрибуты 
интроспекцией (например, reflection) 

e Вовремя исполнения запроса: если 
последующие пары имеют другие типы, 
бросаем ошибку 


class Person { 
Long deptId; 
String name; 


. key dept id name 
BIGINT VARCHAR | VARCHAR 


Трансляция в реляционное дерево 


Attributes 


GROUP BY Aggregate 


name, COUNT(*) 


emp.dept id = dept.id 


emp.dept id 


dept.id 


Оптимизировать синтаксическое дерево проблематично из-за высокой сложности $01-синтаксиса 
Для задачи оптимизации, удобнее представить запрос в виде дерева реляционных операторов с 
простой и строго ограниченной семантикой 

e Большинство трансформаций Apache Calcite работают с реляционными операторами 16 


Реляционные операторы 


Scan Сканировать абстрактный источник данных 
Project Трансформировать кортеж (Hanp., a+b) 


Логические и физические операторы 


e Логические операторы - "uro делать?” 
e Физические операторы — “как делать?” 
e Одному логическому оператору соответствует один или несколько физических 


Трансформации 


Project 
name, COUNT(*) 


Aggregate 


Use 
of inputs 
Remove unused Aggregate 
columns : push-down 
StreamAggregate | 
dept id, COUNT(*) 


] Use index 


IndexScan 
emp 


TableScan 
dept 


e Каждый запрос может быть выполнен несколькими способами 
e Необходимо применить набор трансформаций, чтобы найти оптимальный план 
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Правила трансформации 


Pattern 


Project | 
name, COUNT(*) 
Зот 
agg.dept id = dept.id 


Aggregate 
dept id, COUNT(*) 


Aggregate | 
name, COUNT(*) 


Join 
emp.dept id = dept.id 


Transformation 


Правило состоит из паттерна M логики трансформации 
Apache Calcite содержит порядка 100 готовых логических правил 
Ho Apache Calcite ничего не знает об особенностях вашей системы, поэтому вы должны определить 


физические операторы и соответствующие им правила 
20 


Cost-based оптимизация 


e Кодируем множество 
планов одновременно в 
специальной структуре 
данных (МЕМО) 


(елу 


и 
и 


Aggregate 
name, COUNT(*) 


Join 
emp.dept id = дер] 


J 


Aggregate 
dept id, COUNT(*) 
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Многофазная оптимизация 


Initial 
plan 


Optimized 
plan 


Phase 1 Phase 2 
(heuristic) (cost-based) 


ө Количество альтернативных планов может быть очень большим 
ө Оптимизаторы зачастую разбивают оптимизацию на несколько последовательных фаз, чтобы 
уменьшить количество рассматриваемых планов. Оптимальность не может быть гарантирована 
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Физическая оптимизация: выбор индекса 


SELECT * 

FROM person p 

WHERE salary»1000 AND 
salary«2000 AND 
dept. 2d=10 


ө Разбиваем конъюнктивный предикат на составные части 


e Находим подходящие индексы 
23 


Физическая оптимизация: distribution 


PARTITIONED 


REPLICATED 


SINGLETON 


Каждый оператор имеет свойство 
distribution, которое описывает 
распределение данных в кластере 
PARTITIONED — данные 
распределены по кластеру, каждый 
tuple в одном экземпляре 
(например, IMap) 

REPLICATED — полная копия 
данных на всех узлах (например, 
справочник) 

SINGLETON — данные находятся на 
одном узле (например, 
пользовательский курсор) 
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Каждый оператор может потребовать конкретное распределение у своего инпута 
Если распределение инпута несовместимо с запрошенным, то автоматически вставляем 
специальный физический оператор Exchange, который моделирует перемещение данных в кластере 
Таким образом можно смоделировать выполнение произвольного распределенного 501 -запроса 


25 


Scan 


Optimizer Plan 


Fragment 1 Fragment 2 


Runtime DAG 


Sender — oneparop, 
который отправляет 
данные 


Receiver — оператор, 
который принимает 
данные 


Fragment — дерево 
операторов, которое 
может быть 
исполнено на одном 
узле, независимо от 
других узлов и 
фрагментов 
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Фрагменты 


a i | і " E 


Receiver 


Каждый фрагмент запускается на 
одном или нескольких узлах 
Данные передаются между 
связанными парами 
sender-receiver, пока не достигнут 
пользователя 

Нет промежуточных 


материализаций 
о Высокая производительность 
o Отсутствие fault-tolerance: в случае 
падения узла, запрос необходимо 
перезапускать 
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Структура фрагмента 


Один или несколько input'oB (scan, receiver) 
Один output (sender, user) 

Произвольное количество промежуточных 
операторов 


Операторы 
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Пример: TPC-DS Q3 


select dt.d year, 
item.i brand id brand id, 
item.i brand brand, 
sumi(ss ext sales price) sum agg 
from date dim dt, 
store sales, 


item 
where dt.d date sk = store sales.ss sold date sk 
and store sales.ss item sk = item.i item sk 


and item.i manufact id = 128 
and dt.d moy=11 
group by dt.d year, 
item.i brand, 
item.i brand id 
order by dt.d year, 
sum agg desc, 
brand id 
limit 100 29 


Пример: TPC-DS Q3 


Sender 1 
TNA 
Wii™ 
tN — = 


Pre-Aggregate 
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^ Scan 
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Filter 


Merge Sort 


Aggregate 


i 
Scan 
ITEM 30 


Scan 
STORE SALES 


Volcano Model 


interface Exec { 
void open(); 
Row next(); 
void close(); 
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Volcano—An Extensible and Parallel Query 
Evaluation System 


Goetz Graefe 


Abstract—To investigate the interactions of extensibility and 
parallelism in database query processing, we have developed a 
new dataflow query execution system called Volcano. The Vol- 
cano effort provides a rich environment for research and edu- 
cation in database systems design, heuristics for query opti- 
mization, parallel query execution, and resource allocation. 

Volcano uses a standard interface between algebra орега- 
tors, allowing easy addition of new operators and operator im- 
plementations. Operations on individual items, e.g., predi- 
cates, are imported into the query processing operators using 
support functions. The semantics of support functions is not 
prescribed; any data type including complex objects and any 
operation can be realized. Thus, Volcano is extensible with new 
operators, algorithms, data types, and type-specific methods. 

Volcano includes two novel meta-operators. The choose-plan 
meta-operator supports dynamic query evaluation plans that al- 
low delaying selected optimization decisions until run-time, 
e.g., for embedded queries with free variables. The exchange 
meta-operator supports intra-operator parallelism оп parti- 
tioned datasets and both vertical and horizontal inter-operator 
parallelism, translating between demand-driven dataflow within 
processes and data-driven dataflow between processes. 

АП operators, with the exception of the exchange operator, 
have been designed and implemented in a single-process envi- 
ronment, and parallelized using the exchange operator. Even 
operators not yet designed can be parallelized using this new 
operator if they use and provide the interator interface. Thus, 
the issues of data manipulation and parallelism have become 
orthogonal, making Volcano the first implemented query exe- 
cution engine that effectively combines extensibility and paral- 
lelism, 


Index Terms—Dynamic query evaluation plans, extensible 


database systems, iterators, operator model of parallelization, 
query execution. 


1. INTRODUCTION 

N ORDER to investigate the interactions of extensibil- 

ity, efficiency, and parallelism in database query pro- 
cessing and to provide a testbed for databse systems re- 
search and education, we have designed and implemented 
а new query evaluation system called Volcano. It is in- 
tended to provide an experimental vehicle for research into 
query execution techniques and query optimization op- 
timization heuristics rather than a database system ready 
to support applications. It is not a complete database sys- 


Manuscript received July 26, 1990; revised September 5, 1991, This 
work was supported in part by the National Science Foundation under 
Grams IRI-8996270, TRI 8912618, and IRI-9006348, and by the Oregon 
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tem as it lacks features such as a user-friendly query lan- 
guage, а type system for instances (record definitions), a 
query optimizer, and catalogs. Because of this focus, Vol- 
cano is able to serve as an experimental vehicle for a mul- 
titude of purposes, all of them open-ended, which results 
in a combination of requirements that have not been in- 
tegrated in a single system before. First, it is modular and 
extensible to enable future research, e.g., on algorithms, 
data models, resource allocation, parallel execution, load 
balancing, and query optimization heuristics. Thus, Vol- 
cano provides an infrastructure for experimental research 
rather than a final research prototype in itself. Second, it 
is simple in its design to allow student use and research. 
Modularity and simplicity are very important for this pur- 
pose because they allow students to begin working on 
projects without an understanding of the entire design and 
all its details, and they permit several concurrent student 
projects. Third, Volcano’s design does not presume any 
particular data model; the only assumption is that query 
processing is based on transforming sets of items using 
parameterized operators. To achieve data model indepen- 
dence, the design very consistently separates set process- 
ing control (which is provided and inherent in the Vol- 
cano operators) from interpretation and manipulation of 
data items (which is imported into the operators, as de- 
scribed later), Fourth, to free algorithm design, imple- 
mentation, debugging, tuning, and initial experimentation 
from the intricacies of parallelism but to allow experi- 
mentation with parallel query processing. Volcano can be 
used as a single-process or as a parallel system. Single- 
process query evaluation plans can already be parallelized 
easily on shared-memory machines and soon also on di 

tributed-memory machines. Fifth, Volcano is realistic in 
its query execution paradigm to ensure that students learn 
how query processing is really done in commercial data- 
base products, For example, using temporary files to 
transfer data from one operation to the next as suggested 
in most textbooks has a substantial performance penalty, 
and is therefore used in neither real database systems nor 
in Volcano. Finally, Volcano's means for parallel query 
processing could not be based on existing models since 
all models explored to date have been designed with a 
particular data model and operator set in mind. Instead, 
our design goal was to make parallelism and data manip- 
ulation orthogonal, which means that the mechanisms for 
parallel query processing are independent of the operator 
set and semantics, and that all operators, including new 
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Volcano Model: пример 


class FilterExec implements Exec { 


Exec input; 
Expression filter; 


Row next() { 
while (true) { 


Row row = input.next(); 


if (filter.eval(row)) 
return row; 
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Volcano Model: batching 


interface Exec { interface Exec { 
void open(); void open (); 
Row next (); List<Row> next (); 
void close (); void close(); 
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Volcano Model: неблокирующее выполнение 


interface Exec { interface Exec { 
void open(); void open(); 
List<Row> next(); IterationResult next(); 
void close(); List<Row> currentBatch(); 
void closet); 


e Если оператор He может enum IterationResult { 
продолжить работу, oH возвращает FETCHED 
, 


WAIT 
FETCHED DONE, 
e Родительские операторы передают — 
WAIT вверх no стеку, что приводит к 
освобождению потока 


МАТТ 
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Запуск фрагмента 


WORKER 


void schedule() { 
if (scheduled.cas(false, true)) 
pool.submit(this8);: 


void unschedule() { 
scheduled.set(false); 


if (!batches.isEmpty()) 
schedule (); 
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Кооперативность 


Cooperative Thread Pool 


Фрагменты 


| Е2 | E Worker 2 
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Протокол: запуск запроса 


e = Initiator — координирует 
выполнение запроса 
Participant — обычный участник 
Initiator знает всех узлов- 
участников, и отсылает им ехесще- 
запрос 


ехесще 


ехесще 


ехесще 
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Протокол: запуск запроса 


e Initiator — координирует 
выполнение запроса 
Participant — обычный участник 
Initiator знает всех узлов- 
участников, и отсылает им ехесще- 
запрос 

e Участники начинают обмениваться 
Баїсһ-сообщениями с данными 


ехесще 


ехесще 


"m 


execute 
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Протокол: flow control 


Sender 


e Sender n receiver договариваются о 
количестве “кредитов”. 

e Sender уменьшает количество 
“кредитов” соразмерно количеству 
отправленных байт. Отправка 
сообщений приостанавливается, 

Кесемег когда “кредиты” исчерпаны. 

e Receiver периодически отправляет 
аск-сообщение, которое 
увеличивает количество 
“кредитов” на зепаеге. 
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Протокол: отмена запроса 


e Любой узел может потребовать 
отменить запрос (ошибка, потеря 
узла, запрос пользователя). 

e Participant отправляет cancel 
сообщение на initiator y. 

e Initiator делает broadcast 
сообщения Hà остальных 
participant'oB. 


cancel 


-~O „© 


сапсеі (2) 
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Протокол: отказоустойчив 


Node 


Node 


Node Node 


Node 


e Таккак движок He материализует промежуточные результаты, продолжить выполнение при выходе 
узла из строя проблематично. 
Движок бросит ошибку, но никогда не вернет некорректный результат. 

e Рекомендуем пользователю перезапустить запрос. Достаточно для OLTP проблематично для OLAP. 


e Оптимизатор на основе Apache Calcite 
о Встроенные оптимизации Apache Calcite 
o Выбор вторичных индексов 
o Планирование перемещения данных в кластере (“exchange”) 
e Runtime 
o DAG из фрагментов, которым можно описать запросы произвольной сложности 
o Неблокирующие Volcano-style-uTepatopbi c буферизацией 
o Кооперативная многозадачность 
e Сетевой протокол 
o Оптимизирован под минимизацию latency 
o Flow control для избежания перегрузки узлов 
o Задача отказоустойчивости переложена на пользователя 
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Links 


e Спикер 
o  https;//www.linkedin.com/in/devozerov/ 
o  https:;//twitter.com/devozerov 
e  Hazelcast SQL: 
o  https://github.com/hazelcast/hazelcast/tree/master/hazelcast-sql 
Apache Calcite: 
o  https:;//calcite.apache.org/ 
o  https:;//github.com/apache/calcite 
e  bnor Querify Labs: 
o  https;///www.querifylabs.com/blog 


43 


